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SECTION  I 


INTRODUCTION 


Do  the  hardware  and  software  security  features  of  the  Air  Force 
Data  Services  Center  (AFDSC)  Multics  system  comply  with  the  Department 
of  Defense  security  requirements?  To  answer  thi3  question  AFDSC  com- 
missioned MITRE  to  undertake  a study  to  compare  intrinsic  features  of 
the  AFDSC  Multics  system  with  the  applicable  DoD  requirements.  A3  a 
result  of  this  study  we  conclude  that  the  security  features  of  the 
AFDSC  Multics  system  exhibit  a high  degree  of  compliance  with  all  the 
applicable  requirements  3et  forth  in  DoD  Directive  5200.28  and  expand- 
ed upon  in  DoD  Manual  5200. 28-M. 


BACKGROUND 

The  AFDSC  has  a requirement  to  provide  Automatic  Data  Processing 
resources  and  services  for  the  processing  of  Unclassified  through  Top 
Secret  data  as  support  to  Headquarters  USAF  and  the  Office  of  the  Sec- 
retary of  the  Defense.  To  meet  thi3  requirement  AFDSC  commissioned  a 
joint  Security  Design  Analysis  team  comprised  of  representatives  from 
AFDSC,  USAF  Electronic  Systema  Division,  The  MITRE  Corporation,  and 
Honeywell  Information  Systems.  The  analysis  team  concluded  that  a 
Honeywell  Multics  system,  with  additional  software  controls,  provides 
a reasonable  assurance  that  no  Top  Secret  information  can  be  leaked  to 
a Secret  cleared  individual,  and  that  "need  to  know"  can  be  implemented 
within  these  security  classification  categories.  The  analysis  team  also 
concluded  that  such  a system  i t acceptable  for  operation  in  a controlled 
multi-level  mode,  where  access  to  the  system  is  restricted  to  Secret 
and  Top  Secret  cleared  individuals.  This  current  MITRE  study  inveatigati 
whether  Multics  with  security  enhancements  (henceforth  referred  to  os 
Multics)  complies  with  all  the  DoD  security  requirements. 


MULTICS  SECURITY  CONTROLS 

Multics  contains  a variety  of  hardware  and  software  features  that 
are  supposed  to  provide  secure  operation.  For  the  reader  who  is  not 


familiar  with  these  controls,  we  provide  a brief  overview  of  the  basic 
Multics  security  controls. 

Hardware  ggsasito.  _sga.tr oig. 

Segmentation  Hardware. 

The  most  fundamental  security  controls  in  the  HIS  68/80  Multics 
are  found  in  the  segmentation  hardware.  The  basic  instruction  set  of 
the  68/80  can  directly  address  up  to  64K  segments  at  any  one  time, 
each  segment  being  up  to  256k  words  long.  Segments  are  broken  up  into 
IK  word  pages  which  can  be  moved  between  primary  and  secondary  storage 
by  software,  creating  a very  large  .xrtual  memory. 

Segments  are  accessed  by  the  68/80  CPU  through  segment  descriptor 
words  (SDW's)  that  are  storeu  in  the  descriptor  segment.  Each  SDW 
contains  the  absolute  address  of  the  page  table  for  a segment  and  the 
access  control  information.  The  access  control  information  determines 
user's  access  rights  to  the  segment  - read,  execute,  write,  etc. 

Note  that  by  using  this  access  control  information,  the  supervisor  can 
protect  the  descriptor  segment  from  unauthorized  modification  by  deny- 
ing access  in  the  SDW  for  the  descriptor  segment. 

Protection  Fdngs. 

An  additional  hardware  security  control  on  the  68/80  Multics  sys- 
tem is  the  ring  mechanism.  The  ring  mechanism  extends  the  traditional 
privileged/slave  mode  relationship  of  conventional  machines  to  permit 
layering  within  the  supervisor  and  within  user  code  [8].  Eight  con- 
centric rings  of  protection,  numbered  0-7,  are  defined  with  higher 
numbered  rings  having  less  privilege  than  lower  numbered  rings,  and 
with  ring  0 containing  the  "hardcore"  supervisor.  Execution  of  privi- 
leged mode  instructions  is  confined  to  ring  0.  Each  SDW  specifies  the 
allowed  access  to  each  segment,  for  each  ring  of  execution. 

Software  Controls 

One  advantage  of  Multics  over  other  conventional  systems  is  that 


^he  contents  of  this  section  were  compiled  from  papers  written  by 
Karger  [1]  and  Whitmore  (2'J.  A more  complete  discussion  of  the  vari- 
ous security  controls  can  be  found  in  Lipner  [?],  Saltzer  [4], 
Organick  [5],  and  the  Multics  Programmers  Manual  [6]. 

^A  more  detailed  description  of  the  SDW  format  may  be  found  in  the 
processor  manual  [7]. 
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the  military  clearance  and  classification^  controls  have  been  de- 
signed into  the  Multics.  The  basic  component  of  these  controls  is  the 
implementation  of  the  concept  of  a reference  monitor  — an  abstract 
mechanism  that  controls  access  of  subjects  (active  system  elements)  to 
objects  (units  of  information)  within  the  computer  system  [9].  An  im- 
plementation of  a reference  monitor  must  meet  three  requirements: 

1)  it  must  be  tamperproof;  2)  it  must  always  be  invoked;  and  3)  it 
must  be  small,  simple,  and  understandable  so  that  it  can  be  completely 
tested  and  certified  to  perform  its  functions  properly  [10].  The  Mul- 
tics implementation  of  this  abstraction  consists  of  the  "ring_0"  su- 
pervisor in  conjunction  with  processor  hardware  protection  mechanisms. 

Each  person  registered  on  Multics  is  known  to  the  system  by  his 
name  (person-id)  and  his  project  (project-id),  huS  a password  to  au- 
thenticate his  identity,  and  a clearance  used  to  determine  the  infor- 
mation that  the  user  has  been  cleared  to  observe.  Multics  uses  this 
information  to  ensure  that  a person  cannot  use  the  system  to  obtain 
information  that  he  is  not  entitled  to  (i.e.  that  a person  can  only  have 
access  to  information  for  which  he  has  both  a security  clearance  and  a 
"need  to  know").  To  obtain  service  the  user  logs  in  and  provides  the 
system  with  the  necessary  data  for  authentication.  Upon  completion  of 
the  authentication,  Multics  creates  a proctss  for  the  user,  identified 
by  the  user's  process-id^  and  by  a process  unique-id.  Both  of  these 
identifiers  are  unforgeable  end  remain  constant  for  the  life  of  the 
process.  In  addition  to  the  identifiers,  Multics  also  assigns  to  a 
process  a clearance  that  ,is  constant  for  the  life  of  the  process.  This 
clearance  is  the  minimum  of  the  following:  the  user's  clearance,  his 

project's  clearance,  the  maximum  clearance  of  the  terminal  from  which 
the  user  is  logging  in,  and  the  clearance  specified  by  the  user  before 
the  process  i?  created.  The  user  must  change  processes  when  he  desires 
to  change  his  current  working  clearance. 

A process  is  the  only  subject  on  Multics.  The  set  of  objects  are 
segments,  directories,  I/O  channels,  and  interprocess  messages.  All 
objects  are  protected  according  to  a classification,  assigned  when  the 
object  is. created.  Only  the  system  security  administrator  is  author- 


3 

Within  this  paper  the  terms  clearance  and  classification  refer  to  the 
combination  of  both  a level,  e.g.  Top  Secret  or  Secret,  and  a set  of 
categories,  e.g.  Crypto,  NATO.  The  terms  "access,"  "class,"  and  "authori- 
zation," used  in  Multics  documentation  also  refer  to  this  combination  of 
level  and  categories.  Other  literature  on  multi-level  computer  security 
use  the  terms  clearance  and  classification  to  refer  to  only  the  level 
component,  the  dual  combination  being  referred  to  as  a security  level. 

^A  process-id  is  a combination  of  the  user's  user-id,  his  project-id, 
and  an  instance  tag. 
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ized  to  change  the  classification  of  an  object. 

Multics  compares  the  clearance  of  the  process  to  the  classifica- 
tion of  an  object  each  and  every  time  a process  attempts  to  access  an 
object  in  order  to  ensure  that  the  user  of  the  process  has  the  proper 
clearance  to  perfom  the  desired  operation  (e.g.  read,  write,  execute, 
append,  modify,  delete,  etc.)  Whenever  Multics  compares  the  clearance 
of  a process  with  the  classification  of  an  object  four  relationships 
are  possible. 

less  than 

equal  to 

greater  than 

isolated  from 

The  clearance  of  a process  is  considered  to  be  "equal  to"  the  classi- 
fication of  an  object  if: 

1 . both  have  the  same  level , and 

2.  both  have  identical  category  sets. 

The  classification  of  an  object  is  considered  "less  than"  the  clear- 
ance of  a process  if; 

1.  the  level  of  the  classification  is  less  than  or  equal  to  the  lev- 
el of  the  clearance,  and 

2.  there  are  no  categories  in  the  category  set  of  the  classification 
that  are  not  included  in  the  category  set  of  the  clearance,  and 

3.  the  clearance  is  not  "equal  to"  the  classification. 

The  classification  of  an  object  is  considered  "greater  than"  the 
clearance  of  a process  if: 

1.  the  level  of  the  classification  is  greater  than  or  equal  the 
clearance,  and 

2.  there  is  no  category  in  the  category  set  of  the  clearance  that  is 
not  included  in  the  category  set  of  the  classification,  and 

3.  the  clearance  is  not  "equal  to"  the  classification. 
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The  classification  of  an  object  is  considered  to  have  a relationship 
of  "isolated  from"  the  clearance  of  the  process  if: 

the  classification  of  the  object  is  neither  "less  than",  "equal 
to",  or  "greater  than"  the  clearance  of  the  process. 

In  order  for  a person  to  access  information,  the  military  securi- 
ty system  requires  that  the  clearance  of  the  person  be  "greater  than" 
or  "equal  to"  the  classification  of  the  information.  A sufficient 
condition  for  satisfying  this  requirement  withir.  the  computer  system 
environment  is  the  enforcement  of  the  following  two  rules: 

1.  A process  having  a clearance  n may  not  "read  up",  i.e.  read  an 
object  having  a classification  "greater  than"  n. 

2.  A process  having  clearance  n may  not  "write  down",  i.e.,  write  an 
object  having  a classification  "less  than"  n. 

The  first  of  the  rules,  referred  to  as  the  simple  security  condi- 
tion, directly  implements  the  military  securitv  system,  insofar  as 
clearance  requirements  are  concerned.  The  second  rule,  the  *-property, 
prevents  accidental  or  malicious  disclosure  of  information  due  to  actions 
of  user  programs.  With  these  aforementioned  two  rules  enforced,  it  is 
impossible  for  any  process  to:  1)  extract  Information  from  an  object  of 
a higher  classification;  or  2)  to  transfer  information  from  an  object  of 
higher  classification  to  an  object  of  a lower  classification.  Hence,  no 
compromise  of  classified  information  can  occur.  A further  restriction 
is  also  desirable  which  forbids  a process  to  write  in  an  object  of  higher 
classification  whenever  writing  can  be  used  to  destroy  information.  In 
order  to  provide  some  protection  against  sabotage,  "write  up"  operations 
are  not  permitted  for  such  objects  as  segments,  and  directories. 

It  is  important  to  recognize  that  the  rules  described  above  rep- 
resent a sufficient,  but  not  a necessary  condition  for  achieving  secu- 
rity. Although  the  *-property  restrictions  are  strictly  enforced  for 
all  user  processes,  they  are,  in  certain  circumstances,  relaxed  for 
trusted  processes  that  are  part  of  Multicc;  In  no  circumstances,  how- 
ever, is  the  security  of  the  system  violated. 

In  addition  to  the  formal  clearance  and  classification  controls, 
the  individual  user  is  also  able  to  specify  which  users  have  "need- 
>-o-know"  for  a given  segment  or  directory  by  use  of  the  Access  Control 
List.  The  Access  Control  List  is  a list  of  users  who  are  allowed  to 
accesn  the  segment  or  directory  in  a given  mode  of  access  when  they 
have  the  proper  clearance  as  defined  by  the  formal  controls.  No  user 
can  access  a segment  or  directory  unless  someone  has  extended  to  him 
the  proper  noed-to-know  for  that  object. 
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Multics  can  be  logically  divided  into  two  environments:  internal 

and  external.  The  internal  environment  is  totally  controlled  by  Mul- 
tics and  includes:  processors,  memory,  disk  drives,  I/O  multiplexors, 

bulk  store,  communication  processors,  and  tape  drives  used  for  system 
functions.  The  external  environment  can  be  directly  influenced  by  the 
actions  of  a process.  Included  in  the  external  environment  are:  ter- 

minals, line  printers,  card  readers,  card  punches,  non-system  tape 
drives,  and  other  devices  of  the  I/O  class  not  used  for  system  func- 
tions. To  provide  a "secure”  pipeline  between  the  internal  and  exter- 
nal enviror.nents,  Multics  performs  the  actual  information  transfer  on 
behalf  of  the  user,  giving  a reasonable  assurance  that  failures  or 
"software  bugs"  in  I/O  software  can  not  be  exploited  by  a user.  The 
terminal  is  the  only  exception  to  this  rule.  Users  may  perform  direct 
I/O  to  the  terminal  that  the  system  has  attached  to  the  process.  Ter- 
minal software  has  been  carefully  checked  out  in  an  effort  to  elimi- 
nate software  errors.  The  exception  for  terminals  is  only  made  for 
the  sake  of  efficiency. 


SCOPE 


This  compliance  study  is  concerned  only  with  the  DoD  hardware  and 
software  security  requirements.  Additional  requirements  must  also  be 
met  for  the  system  to  be  considered  secure.  These  include  require- 
ments for  physical  protection  and  policies  for  administration  of  the 
system  [11],  [12],  [13].  Although  these  issues  are  important  to  the 
overall  security  of  the  system  we  felt  the  addition  of  Multics  at  the 
AFDSC  site  would  have  little,  if  any,  effect  on  them,  since  AFDSC 
already  has  a secure  environment.  Therefore,  requirements  for  physical 
security  and  administrative  policy  are  only  reviewed  if  the  addition 
of  Multics  might  have  some  effect  on  the  controls  already  in  effect  at 
the  AFDSC. 

The  remainder  of  this  report  is  divided  into  two  sections.  In 
Section  II  the  seven  minimum  requirements  that  "insofar  as  possible" 
must  be  complied  with  [14]  are  reviewed.  The  reviews  are  in  the  form 
of  a quotation  of  the  requirement  followed  by  Multics  compliances. 

In  Appendix  I an  item  by  item  comparison  is  undertaken  between 
the  guidelines  for  the  particular  techniques  and  procedures  needed  to 
implement  the  seven  requirements  [15]  and  the  particular  security 
controls  provided  by  Multics. 
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SECTION  II 

COMPLIANCE  TO  DoD  DIRECTIVE  5200.28 


Department  of  Defense  Directive  5200.28  establishes  a policy  for 
protecting  data  handled  by  an  Automatic  Data  Processing  (ADP)  System 
and  defines  administrative  responsibilities  for  assuring  the  security 
policy  is  carried  out.  It  is  intended  that  the  AFDSC  Multics  system 
process  Unclassified  thru  Top  Secret  data  in  a controlled  multi-level 
mode,  where  access  to  the  system  is  restricted  to  Secret  and  Top  Se- 
cret cleared  individuals.  Therefore  the  system  must  comply  to  the 
Minimum  Requirements  as  set  forth  in  DoD  Directive  5200.28.  Each  of 
the  following  subsections  consist  of  a requirement  from  Section  VI  of 
5200.28  followed  by  a discussion  of  the  compliance. 


INDIVIDUAL  ACCOUNTABILITY 

IV. A. 1 Each  user's  identity  shall  be  positively 
established,  and  his  access  to  the  system,  and  hi3 
activity  in  the  system  (including  material  access- 
ed and  actions  taken)  controlled  and  open  to  scru- 
tiny. 

The  Mul.i  3 system  complies  with  the  requirement  for  individual 
accountability  by  authenticating  the  individual  before  allowing  access 
to  the  system  and  by  ensuring  that  once  access  is  allowed  and  a pro- 
cess for  the  individual  is  created,  a correspondence  can  always  be 
made  between  the  process  and  the  individual  for  whoa  the  process  was 
created.  The  principal  neans  of  making  this  correspondence  is  the 
process-id,  an  uaforgeable  identifier  consisting  of  a combination  of 
the  individual's  name,  his  project,  and  an  instance  tag.  The 
process-id  together  with  the  process's  clearance, set  only  when  the 
process  is  created  (see  Section  I),  are  characteristic  datum  used  to 
control  the  individual's  activities  on  the  system.  No  action  is  pos- 
sible unless  the  individual  is  authorized  to  perform  the  action. 

Kultics  establishes  the  correspondence  between  the  process-id  and 
the  individual  by  means  of  a system  generated  pronounceable  password 
[16]  At  each  login  the  individual  presents  the  system  with  his  name 
and  password.  The  system  verifies  the  correctness  of  the  password  be- 
fore allowing  the  individual  to  proceed.  Incorrect  login  attempts  are 
audited  to  assure  that  an  unreasonable  number  of  incorrect  passwords 
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is  not  used  to  verify  the  correspondence  between  the  user  name  and 
password.  Periodic  changing  of  the  passwords  is  at  the  discretion  of 
the  System  Security  Administrator. 

Upon  completion  of  the  initial  login  a message  is  sent  by  the 
system  to  the  system  log  indicating  the  name  of  the  individual  who 
logged  in,  from  what  terminal  the  login  originated,  and  at  what  time 
the  login  occurred.  In  this  way  an  individual's  usage  of  the  system 
is  open  to  inspection.  Similarly,  each  logout  is  also  reco.-ded  in  the 
system  log. 

To  increase  the  effectiveness  of  the  controls  certain  other  ac- 
tions are  recorded.  These  actions  include  an  attempt  to  access  a seg- 
ment or  directory  with  improper  authorization,  illegal  procedure 
faults,  attempts  to  "send  down"  an  Inter-Process  Communication  message 
to  a process  having  improper  authorization,  rejection  of  requests  for 
attachment  of  I/O  devices,  and  rll  setting  and  resetting  of  the  system 
privilege  bits. 


ENVIRONMENTAL  CONTROL 

IV. A. 2 Tne  ADP  system  shall  be  externally  protect- 
ed to  minimize  the  likelihood  of  unauthorized  ac- 
cess to  system  entry  points,  access  to  classified 
information  in  the  system,  or  damage  to  the  sys- 


The  addition  of  the  Kultics  system  to  the  Air  Force  Data  Services 
Center  Computer  Center  does.not  adversely  affect  the  physical  security 
controls  already  in  effect. 


SYSTEM  STABILITY 

IV. A. 3 All  elements  or  components  of  the  ADP  Sys- 
tems shall  function  in  a cohesive,  identifiable, 
predictable,  and  reliable  manner  so  that  malfunc- 
tions are  detected  and  reported  within  a known 
time. 


^System  privilege  bits  must  be  set  before  performing  operations  that 
bypass  certain  security  controls. 

discussion  of  the  physical  security  controls  appear  in  Wilson  (12 j, 
Irvin  [13],  AFDSCR  171-1  [17],  and  AFD5CI  300-8  [11]. 
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Hultics  complies  with  the  requireaent  for  systea  stability  by 
providing  cohesive  documentation  on  systea  software  [6]  and  by  having 
available  a set  of  test  procedures  that  test  the  proper  operation  of 
the  security  related  features. 

The  tests  for  Hultics  are  divided  into  hardware  tests  [18]  and 
software  tests  [19].  The  hardware  tests  check  the  reliability  of  the 
hardware  operations.  Understandably  each  possible  hardware  state  can- 
not be  explicitly  checked.  However  an  extensive  analysis  of  features 
closely  related  to  security  can  be  undertaken.  The  analysis  of  the 
hardware  is  performed  by  a systea  subverter,  a utility  invoked  period- 
ically to  audit  the  status  of  the  systea.  The  subverter  checks  for 
the  proper  operation  of  all  possible  machine  instructions,  the  segment 
access  controls,  and  the  ring  structure.  Should  the  result  of  a test 
indicate  abnormal  systea  behavior  the  operator  is  notified,  thereby 
enabling  corrective  actions  to  be  taken.  The  results  of  all  tests  are 
recorded  to  aid  in  determining  the  frequency  of  future  tests. 

The  software  ttsts  are  designed  to  aid  in  the  verification  that  the 
security  controls  perfora  exactly  as  specified.  On  Hultics  the  ring 
structure  provides  a mechanism  for  layering  software  controls.  The 
software  tests  check  the  aost  primitive  operations  available  to  the 
user  to  ensure  that  a user  cannot  bypass  the  security  controls.  If  an 
error  is  detected  the  operator  is  notified,  thereby  allowing  correc- 
tive measures  to  be  performed.  The  areas  tested  are  the  process 
clearance  assignment,  access  to  segments,  access  to  directories,  com- 
munication between  processes,  auditing,  the  systea  security  adminis- 
trator commands,  and  access  to  I/O. 


DATA  INTEGRITY 

IV. A. A Each  file  or  collection  of  data  in  the  AD? 

Systea  shall  have  an  identifiable  origin  and  use. 

Its  accessibility,  maintenance,  movement,  and  dis- 
position shall  be  governed  on  the  basis  of  securi- 
ty classification  and  need-to-know . 

As  pointed  out  in  Section  I a primary  advantage  of  the  Multics 
system  with  security  enhancements  is  that  data  integrity  has  been  de- 
signed into  the  system.  Hultics  bases  its  security  policy  on  a mathe- 
matical model  [20]  [21].  The  model  states  that  an  individual  cannot 
access  any  information  above  his  security  clearance.  In  addition, 
even  if  an  individual  has  the  proper  security  clearance  to  access  in- 
formation, that  individual  must  still  have  been  extended  the  proper 
need-to-know.  To  prevent  accidental  or  malicious  disclosure,  the  mod- 
el also  requires  that  an  individual's  process  cannot  inadvertently  or 
deliberately  transfer  information  to  an  object  that  has  a classifica- 


tion  lower  than  the  process's  security  clearance. 

By  adhering  to  the  aatbeaatical  model,  Hultics  coaplies  to  the 
requireaents  on  data  accessibility,  Maintenance,  and  aoveaent.  Dele- 
tion of  a file  on  the  systea  is  governed  by  security  classification 
and  need-to-know . The  Model's  security  rules  also  apply  to  input  and 
output.  Therefore,  the  Hultics  systea  coaplies  with  the  requireaent 
of  disposition. 


SYSTEM  RELIABILITY 

IV. A. 5 The  systea  shall  function  so  that  each  user 
has  access  to  all  of  the  information  to  which  he 
is  entitled,  but  no  aore. 

Hultics  coaplies  with  the  requireaent  for  systea  reliability  by 
providing  clearance  and  classification  controls,  need-to-lcnow  access 
controls,  and  a hardware  access  control  aechanisa  that  divides  the 
systea  into  eight  linearly  ordered  doaains  [22].  These  doaains,  re- 
ferred to  as  rings  (see  Section  I),  provide  an  additional  aeans  of  re- 
stricting the  process's  address  space.  To  deny  direct  access  to  sys- 
tea inforaation  that  an  individual  does  not  have  the  right  to  observe 
or  aodify,  Hultics  places  the  systea  inforaation  in  ?.  ring  that  the 
individual's  progr&a  is  not  able  to  access  directly.  The  hardware  en- 
forces the  access  control  aechanisas  by  checking  access  before  each 
and  every  aeaory  reference. 


COMHUMICATION  LINKS 

IV. A. 6 These  links  and  lines  shall  be  secured  in  a 
Banner  appropriate  for  the  Material  designated  for 
transaission  through  such  lines  or  links. 

Hultics  will  handle  aaterial  up  to  a classification  of  Top  Se- 
cret. In  order  to  comply  with  this  requireaent,  coaaunication  lines 
are  encrypted  in  a manner  suitable  for  the  inforaation. 


CLASSIFIED  MATERIAL 

IV. A. 7 Such  material  handled  and  produced  by  the 
ADP  System  or  stored  in  or  on  media  for  recording 


7 

See  Section  I for  a more  detailed  discussion  of  the  access  controls 
provided  by  Hultics. 
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classified  aaterial  aaterial  shall  be  safeguarded 
as  appropriate  for  the  classification  assigned  to 
the  information. 

On  Multics,  before  each  item  of  printed  output  is  produced,  a 
nonsuppressible  security  banner  is  printed.  In  addition  security  la- 
bels are  printed,  at  the  option  of  the  individual  user,  at  the  top  and 
bottoa  of  each  page  of  output  [23].  With  each  piece  of  printed  out- 
put, an  accountability  fora  is  also  produced  containing  the  name  of 
the  individual  who  requested  the  output,  the  name  of  the  document  pro- 
duced, the  classification  of  the  document,  and  other  information  use- 
ful in  the  distribution  of  classified  aaterial. 

Magnetic  tapes  produced  by  the  Multics  system  can  only  contain 
information  of  a single  security  level,  defined  manually  by  the  opera- 
tor before  the  tape  is  mounted  [24].  Likewise  card  output  can  only 
occur  at  a single  security  level,  defined  to  be  the  current  level  of 
the  card  punch.  A security  level  banner  is  punched  preceding  each 
punched  deck  to  provide  a greater  level  of  security  protection.  Upon 
removal  from  the  system,  manual  security  controls  apply  to  all  types 
of  output  [11], 

Because  all  forms  of  output  follow  the  guidelines  set  forth  in 
5200.28,  Multics  complies  with  the  requirement  that  classified  materi- 
al produced  be  safeguarded  as  appropriate. 

The  security  controls,  mentioned  in  Section  I,  control  all  access 
to  classified  aaterial  handled  within  the  computer  system  regardless 
of  the  media  the  data  is  stored  on.  All  media  used  for  the  storage 
(including  Backup  Tapes  and  Dump  Tapes)  of  classified  material  within 
the  system  is  classified  Top  Secret  [2],  and  may  not  be  removed  from 
the  installation  without  applying  the  appropriate  physical  security 
controls  [11]. 


SECTION  III 


CONCLUSION 


After  a thorough  examination  cf  the  security  features  and  meas- 
ures provided  by  Multics,  we  conclude  that  Multics  meets  the  objective 
of  Department  of  Defense  Directive  5200.28.  Multics  provides  a combi- 
nation of  hardware  security  controls  (including  segmentation,  rings, 
and  a virtual  memory)  and  software  security  controls  (the  Implementa- 
tion of  the  military  clearance,  classification,  and  need-to-know  con- 
trols). In  a secure  environment,  these  controls  provide  the  user  with 
accountability,  stability,  integrity,  reliability,  and  protection  of 
classified  material  controls.  Multics  is  thus  suitable  to  handle  Un- 
classified through  Top  Secret  data  in  a controlled  multi-level  envi- 
ronment, where  access  is  restricted  to  Secret  and  Top  Secret  cleared 
individuals. 
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APPENDIX  I 


COMPLIANCE  TO  DoD  MANUAL  5200. 28-M 


In  this  appendix  facilities  provided  by  Honeywell's  Multic3  sys- 
tem are  compared  to  the  techniques  and  procedures  set  forth  in  ADP  Se- 
curity Manual  5200. 28-M.  The  purpose  of  5200. 28-M  is  to  provide  guid- 
ance to  aid  in  meeting  the  general  objective  of  having  a dependable 
secure  computer  system.  Sections  of  5200. 28-M  discuss  the  developing, 
designing,  acquiring,  analyzing,  testing,  evaluating,  establishing  and 
approving  of  methodologies,  standards,  criteria,  specifications',  tech- 
niques and  procedures  to  be  used  in  securing  an  ADP  computer  system. 
Honeywell  has  addressed  the  objective  of  developing  a secure  computer 
system  in  two  ways:  1)  by  examining  any  module  that  might  deal  with 

security  to  ascertain  that  the  security  controls  cannot  be  circumvent- 
ed; and  2)  by  developing  access  controls  suitable  for  secure  multi- 
level operation,  in  a controlled  environment  [2].  Because  it's  de- 
signers specifically  addressed  circumvention  and  access  control  media- 
tion, Honeywell's  Multics  system  can  be  expected  to  have  a dependable 
secure  computer  system.  . 

Following  is  an  item  by  item  comparison  between  each  of  the  spe- 
cific hardware  and  or  software  requirements  set  forth  In  5200. 28-M  and 
the  security  measures  provided  by  the  Multics  system.  Unless  other- 
wise stated  Section  numbers  used  within  this  Appendix  refer  to  Section 
numbers  of  5200. 28-M. 


PERSONNEL  SECURITY  SECTION  II 

Clearance  and  Access  Controls  II. 1 

Section  II  covers  Personnel  Security  Clearance  and  Access  Con- 
trols. Personnel  Security  Clearance  and  Access  Control  are  discussed 
in  the  Security  Procedures  Manual  [13]. 


PHYSICAL,  COMMUNICATIONS,  AND  EMANATIONS  SECURITY  SECTION  III 

Section  III  of  DoD  5200. 28-M  deals  with  Physical,  Communications, 
and  Emanations  Security.  The  requirements  covered  are  fulfilled  by 
the  procedures  specified  in  the  AFDSC  installation  Security  Procedures 
Manual . 


19 


uiumkmd 


I 


1 


HARDWARE/ SOFTWARE  FEATURES  SECTION  IV 

Hardware  JUL  2 

Section  IV,  Part  2,  of  5200. 28-H  presents  hardware  requirements 
for  a secure  computer  system.  Each  of  the  11  requireaents  presented 
is  reviewed  below.  A more  complete  description  of  the  hardware  fea- 
tures discussed  can  be  found  in  Section  I of  this  compliance  report. 

4-200  Hardware  Features 

Paragraph  4-200. a defines  the  requirement  for  protected  state 
variables.  The  Multics  system  provides  8 levels  of  isolation  in  the 
form  of  concentric  hardware  rings.  A process's  current  ring  of  execu- 
tion defines  the  set  of  executable  instructions.  The  operating  systea 
and  security  sensitive  data  reside  in  the  aost  protected  rings. 

Paragraph  4-200. b deals  with  the  ability  of  a processor  to  access 
locations  in  memory.  A processor  can  only  access  segments  through 
segment  descriptor  words  (SDWs)  defined  in  a descriptor  segment.  Each 
SDW  contains  access  bits,  defining  the  allowable  mode  of  access  to 
specified  memory  locations,  in  each  ring  of  execution.  The  access 
control  bits  are  only  set  if  the  processor  has  the  proper  classifica- 
tion and  need-to-know . 

Paragraph  4-200. c deals  with  controlling  the  availability  of  cer- 
tain instructions.  The  68/80  processor  has  two  modes  of  execution, 
privileged  and  non-privileged.  Security  sensitive  instructions,  such 
as  the  Instructions  performing  input  and  output,  can  only  be  executed 
in  privileged  mode.  Privileged  mode  is  protected  by  restricting  its 
use  to  processes  executing  in  rJng  0,  the  most  privileged  ring. 

Paragraph  4-200. d states  that  all  possible  operation  codes  should 
produce  known  responses.  Operation  codes  on  the  68/80  are  tested  by  a 
hardware  subverter  [ 18 ] . The  subverter  dynamically  checks  each  in- 
struction against  known  results.  Should  an  unknown  response  ever  b? 
found  the  subverter  notifies  the  system  operator. 

Paragraph  4-200. e deals  with  error  detection  of  registers  funda- 
mental to  the  secure  operation  of  the  system.  The  use  of  these  regis- 
ters is  restricted  to  processes  in  the  proper  mode  and  ring  of  execu- 
tion [7].  In  addition,  the  hardware  subverter  checks  these  registers 
for  reliability  errors. 

Paragraph  4-200. f states  that  all  registers  that  can  be  loaded  by 
the  operating  system  should  also  be  storable.  All  registers  on  the 
68/80  are  storable  by  the  operating  system  [7]. 
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Paragraph  4-200. g states  that  error  detection  should  be  performed 
on  each  fetch  cycle  of  an  instruction.  On  the  68/80  each  meaory  ac- 
cess is  controlled  by  addressing  a segment  through  a segment  descrip- 
tor word  (SOW).  Detectable  errors  include  address  out  of  range  and 
improper  authorization  to  access  [7] . 

Paragraph  4-200. h expands  the  need  for  error  detection  to  include 
transfer*  of  data  between  memory  and  storage  devices.  The  68/80  pro- 
vides error  detection,  parity  checks,  and  in  some  cases  redundancy 
checks  cn  transfers  to  and  from  bulk  store,  disk,  the  system  control- 
ler and  the  CPU. 

Paragraph  4-200.1  deals  with  automatic  programmed  interrupts. 

The  68/80  provides  a programmable  fault  vector  that  determines  actions 
to  be  taken  when  system  or  operator  malfunctions  occur  [7]. 

Paragraph  4-200. j states  that  the  identity  of  remote  terminals 
should  be  controlled  by  hardware.  On  the  68/80  each  remote  terminal 
is  connected  to  a port  (channel).  Channel  numbers  are  fixed  in  hard- 
ware allowing  the  operating  system  to  positively  establish  the  identi- 
ty of  each  terminal  [2]. 

Paragraph  4-200. k identifies  the  need  for  verifying  the  read, 
write,  and  execute  access  rights  of  a user  on  each  fetch  cycle  of  an 
instruction.  As  stated  in  Section  1 of  this  compliance  report,  all 
access  to  information  is  controlled  in  hardware  by  the  use  of  SDWs. 
Included  in  each  SDW  are  the  user's  read /write  and  execute  rights. 

frftwrg  IV  ,3 

4-300  (fcngral 

Paragraph  4-300  identifies  the  need  to:  1)  separate  the  control 
part  of  the  operating  system  from  the  user;  and  2)  to  keep  the  control 
part  as  small  as  possible.  The  Hultics  system  complies  with  this  re- 
quirement by:  1)  only  having  a few  central  sections  of  the  operating 
system  execute  in  privileged  mode;  and  2)  having  all  the  modules  nec- 
essary for  the  secure  operation  of  the  system  execute  in  the  most 
privilege  rings,  the  rest  of  the  operating  system  executes  in  the  same 
ring  as  other  user  programs. 

4-301  Q/S_Csot.rql 

Paragraph  4-301  identifies  the  minimum  controls  the  operating 
system  shall  contain.  Each  requirement  is  reviewed  below.  Further 
information  on  the  security  features  of  the  Multics  software  can  be 
found  in  Section  I of  this  compliance  report. 
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Paragraph  4-301 .a  requires  the  operating  systea  to  control  all 
transfers  of  Material  between  aeaory  and  on  line  storage,  between  the 
central  conputer  facility  equipment  and  any  reaote  device,  or  between 
on  line  storage  devices.  The  Multics  systea  is  a virtual  aeaory  sys- 
tea and  as  such  the  operating  systea  controls  all  transfers  between 
aeaory.  On  line  storage  on  Multics  is  considered  an  extension  of  aea- 
ory and  thus,  is  controlled  by  the  operating  systea.  The  Multics  sys- 
tea also  controls  all  output  to  and  input  froa  reaote  devices. 

Paragraph  4-301. b requires  that  the  operating  systea  control  al- 
location of  all  systea  resources,  aeaory  protection,  systea  interrupt 
and  shifting  between  user  and  master  modes.  The  Multics  systea  con- 
trols the  allocation  of  all  systea  resources.  Memory  protection  is 
accomplished  by  the  operating  system  controlling  segment  descriptor 
words.  Systea  interrupts  are  handled  by  the  operating  system.  Privi- 
leged mode  protection  is  controlled  because  the  operating  system  re- 
ceives control  at  a known  place  when  the  user  attempts  to  enter  privi- 
lege mode. 

Paragraph  4-301. c requires  that  access  to  system  utilities  be 
controlled.  The  Multics  system  controls  access  to  these  utilities  by 
the  use  of  Access  Control  Lists  (ACLs).  Only  those  users  who  have  a 
definite  need  to  access  or  use  these  utilities  are  included  on  the 
ACLs. 


Paragraph  4-301 .d  requires  the  operating  system  to  control  the 
user  program's  access  to  material  and  requires  the  operating  system  to 
control  the  user  identification  system.  The  Multics  operating  system 
controls  user  access  to  material  by  using  security  classification  and 
need-to-know  controls.  The  user  identification  system  is  also  con- 
trolled by  t***  "grating  system. 

4—302  ieat_aM  pefrug&irjs  .PcaarMa 

Paragraph  4-302  requires  that  only  programs  that  do  not  violate 
the  security  or  integrity  of  the  system  may  be  debugged  during  system 
operation.  This  requirement  is  adhered  to  by  the  Air  Force  Data  Serv- 
ices Center. 

4-303  Clear  System  Procedures 

Paragraph  4-303  requires  that  procedures  be  available  for  clear- 
ing from  the  system  all  classified  material  during  operation  of  the 
system  without  the  required  protection.  Although  procedures  exist  for 
system  clearing  (13],  the  AFDSC  Multics  system  always  operates  in  a 
controlled  environment  with  a maximum  classification  of  Top  Secret. 


*-301  Shutdown  and  Restart 


Paragraph  4-304  requires  the  operating  systea  to  provide  security 
safeguards  to  cover  systt«  shutdown  (both  scheduled  and  unscheduled) 
and  subsequent  restarts  On  Hultics  shutdown  and  restart  are  under 
the  control  of  the  operating  systea.  When  a shutdown  occurs,  cooauni- 
cation  between  the  front-end  processor  and  Hultics  is  severed  by  the 
operation  systea.  Severing  the  communication  lines  removes  any  possi- 
bility that  a user  could  access  the  systea  until  the  system  restarts. 

4-305  Other  Pundaaental  Features 

Paragraph  4-305  lists  other  features  of  the  operating  system  con- 
sidered fundamental  to  the  secure  operation  of  the  system.  In  addi- 
tion, paragraph  4-305  requires  that  attempts  to  circumvent  the  securi- 
ty controls  be  detectable,  reported  within  a known  time,  and  recorded 
in  the  audit  log.  The  requirement  for  an  audit  log  will  be  discussed 
in  the  following  subsection  of  this  report.  Each  of  the  six  addi- 
tional features  in  paragraph  4-305  are  reviewed  below. 

Paragraph  4-305. a requires  that  the  operating  system  control  re- 
source allocation,  memory  access  outside  assigned  areas,  and  the  exe- 
cution of  master  mode  instructions.  The  Multics  operating  system  han- 
dles resource  allocation  by  controlling  segmentation  and  demand  paging 
routines.  All  pages  are  allocated  or  removed  from  memory  by  the  oper- 
ating system.  Memory  access  outside  the  assigned  areas  is  controlled 
by  a combination  of  hardware  and  software  controls.  The  operating 
system  controls  the  fields  of  the  hardware  SDW's  and  page  tables  while 
the  hardware  performs  checks  on  the  values  in  these  fields.  Multics 
controls  the  execution  of  master  mode  instructions  by:  1)  only  allow- 
ing execution  of  these  instructions  in  the  most  privileged  ring;  and 
2)  by  controlling  the  access  control  lists  on  the  entry  gates  to  this 
privileged  ring. 

Paragraph  4-305. b requires  that  the  system  ensure  that  classified 
material  or  critical  elements  of  the  system  do  not  remain  as  accessi- 
ble residue  in  memory  or  on  on-line  storage  devices.  A process  can 
only  directly  access  memory  by  accessing  a segment.  Multics  will  not 
let  a process  access  a segment  unless  the  process  has  the  proper  secu- 
rity clearance,  the  process  is  in  the  proper  ring,  and  the  name  of  the 
process  is  on  the  access  control  list  of  the  segment.  When  a process 
attempts  to  access  an  authorized  segment  that  is  not  in  main  memory, 
the  operating  system  transfers  the  segment  into  addressable  memory, 
overwriting  any  residual  data.  The  operating  system  also  removes  re- 
sidual data  when  new  pages  are  created,  by  writing  zeroes  into  all  ad- 
dresses in  the  new  page,  before  access  is  allowed.  Therefore  accessi- 
ble memory  can  only  contain  zeroes  or  information  that  the  process  i3 
entitled  to  observe. 
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Paragraph  4-305. c of  DoD  5200. 28-M  deals  with  the  requirement  for 
a Systea  Security  Officer.  On  Multics,  the  Systea  Security  Officer, 
referred  to  as  the  Systea  Security  Administrator,  has  the  responsibil- 
ity: to  assign  users'  security  clearances,  to  periodically  force  users 
to  change  their  passwords,  to  repair  any  security  related  inconsisten- 
cies, and  to  downgrade  information  [2].  These  functions  coaply  with 
the  requireaents  set  forth. 

Paragraph  4-305. d requires  that  there  be  appropriate  security  la- 
bels on  all  data  input  to,  stored  in,  or  output  froa  the  AOP  systea. 

The  Hultics  system  keeps  a security  label  for  each  segaent  on  the  sys- 
tea. The  security  label:  1)  Identifies  the  sensitivity  of  the  infor- 
mation; 2)  is  used  to  control  the  accessibility  of  the  segment;  and 
3)  can  only  be  decreased  by  an  action  of  the  Systea  Security  Adminis- 
trator. The  nonsuppressible  security  banner,  printed  with  each  out- 
put, is  never  less  than  the  security  label  of  the  segment,  and  is  used 
in  the  determination  of  the  label  printed  on  the  output.  Security  la- 
bels are  discussed  further  in  Section  II  of  this  report  under  the  re- 
quirement for  Data  Integrity. 

Paragraph  4-305.e  states  that  administrative  and/or 
hardvare/8oftvare  measures  be  established  to  assure  that  terminals  are 
protected  and  are  authorized  access  to  specific  levels  of  information. 
AFDSC  meets  these  requirements  by:  1)  providing  software  controls  that 

specify  the  highest  level  of  the  information  that  can  be  accessed  from 
each  terminal;  2)  restricting  access  to  terminals  to  properly  cleared 
personnel;  and  3)  placing  all  terminals  in  areas  that  provide  protr  jn 

to  the  highest  level  of  information  that  can  be  accessed. 

Paragraph  4-305. f requires  that  the  user  and/or  the  group  of  u~<rs 
to  which  the  individual  user  belongs  must  be  accurately  identified  to 
the  ADP  system.  Users  are  identified  to  Multics  by  a combination  of: 

1)  a user  name;  2)  a user  project:  and  3)  a password  that  was  system 
generated.  A security  clearance  of  a process  is  determined  by  the 
lesser  of:  1)  the  security  clearance  of  the  room  in  which  his  terminal 
resides;  2)  the  security  clearance  the  user  gives  as  a parameter  when 
logging  into  the  system;  3)  the  user's  own  clearance;  4)  his  projects 
clea  ance;  and  5)  his  clearance  on  the  project. 


AUDIT  LOG  OF  FILE  SECTION  V 
5-100  Application 

Paragraph  5-100  requires  that  an  audit  file  or  log  be  maintained 
to  record  security  related  transactions.  Multics  complies  with  this 
requirement  by  compiling  two  system  logs:  the  System  Log  and  the 


Syserr  Log. 


The  Systea  Log  records  normal  system  entry  and  exit,  denied  sys- 
tem entry,  and  installations  of  new  systea  tables  dealing  with  user 
names,  projects,  and  authorizations. 

The  Syserr  Log  contains  entries  for:  initiations  of  protected 
segments,  denied  access  to  any  segment  or  directory,  access  violation 
faults,  illegal  procedure  faults,  attempts  to  "send  down"  an  IPC  mes- 
sage to  a process  having  an  improper  authorization  inconsistencies  in 
the  file  hierarchy,  rejection  of  requests  for  attachment  of  devices, 
and  setting  and  resetting  the  system  privilege  bits. 

Ir,  addition  to  the  logs  compiled  by  the  system,  an  accountability 
form  is  produced  with  each  printed  output.  The  accountability  form 
includes  the  user  name,  project,  date  and  time  requested,  classifica- 
tion, pathname,  sequence  number,  printed  name  of  document,  and  places 
for  the  signatures  of  the  carrier  and  recipient  if  needed. 


BASIC  SAFEGUARDS  SECTION  VI 

Section  VI  of  the  manual  discusses  classified  material  ’'removed 
from  the  custody  of  the  system”  and,  as  such,  does  not  fal1  within  the 
scope  of  this  compliance  study.  Controls  dealing  with  the  removal  of 
classified  material  previously  in  effect  at  AFDSC  remain  in  effect. 


ERASE  AND  DECLASSIFICATION  PROCEDURES  SECTION  VII 

Part  1 of  Section  VII  requires  that,  "each  memory  location  used 
for  the  storage  of  classified  data  shall  be  overwritten  when  it  is  no 
longer  required,  before  reutiiization,  or  before  the  content  of  the 
location  may  be  read  to  preclude  the  unauthorized  disclosure  of  clas- 
sified data".  Multics  does  exactly  that  by  preventing  unauthorized 
access  to  a segment,  and  by  overwriting  memory  before  a process  is  al- 
lowed to  access  an  authorized  segment.  A user's  process  can  only  gain 
access  to  main  memory  by  accessing  a segment.  The  only  segments  ac- 
cessible are  active  ones  to  which  the  user  explicitly  has  access. 

When  the  user  accesses  a given  segment,  that  segment,  or  part  of  it, 
is  placed  into  main  memory,  overwriting  whatever  was  there  before. 
Creating  a new  page  in  a segment  causes  memory  to  be  overwritten  with 
zeroes  before  access  to  the  new  page  is  allowed.  Therefore,  accessi- 
ble memory  can  only  contain  zeroes  or  information  that  the  process  is 
entitled  to  observe. 

Section  VII,  Parts  2 and  3 discuss  erase  procedures.  Erase  pro- 
cedures are  operational  policies  outside  the  scope  of  this  compliance 
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study.  Procedures  already  in  effect  at  AFDSC  should  require  no 
change . 


SPECIFICATIONS  FOR  MAGNETIC  TAPE  ERASE  EQUIPMENT  SECTION  VIII 

Section  VIII  states  the  specifications  for  magnetic  tape  erase 
equipment.  Magnetic  tape  erase  procedures  were  not  specifically  ad- 
dressed by  this  compliance  study.  Procedures  previously  in  effect 
continue  unchanged  with  the  addition  of  the  Multics  system. 


SECURITY  TESTING  AND  EVALUATION  (ST&E)  SECTION  IX 

Section  IX,  Parts  1 and  2,  deal  with  the  security  testing  and 
evaluating  of  the  security  controls  provided  by  the  ADP  system.  On 
the  Multics  system  security  testing  is  divided  into  two  parts:  hard- 
ware testing  and  software  testing.  The  hardware  tests  are  made  by  a 
subverter  program  [18]  that,  among  other  things,  attempts  to  subvert 
the  system  by  executing  illegal  hardware  instructions.  The  purpose  of 
the  subverter  program  is  to  find  hardware  errors  that  a penetrator 
could  use  to  bypass  the  software  security  controls.  In  an  effort  to 
find  hardware  errors  in  a reasonable  time,  the  subverter  is  run  peri- 
odically as  a normal  Multics  job. 

Software  security  controls  are  tested  periodically  by  running  a 
series  of  programs  that  check  the  correctness  of  the  various  controls 
[19].  Each  major  section  of  the  system  has  its  own  set  of  test  proce- 
dures. These  test  procedures  are  run  each  time  the  software  is 
changed  to  reduce  the  possibility  of  introducing  security  errors  into 
the  system.  In  addition,  these  test  procedures  are  run  periodically 
to  insure  that  the  software  is  properly  handling  security  related 
events. 
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